﻿
/*问：IDataPipeFrom只能从数据源拉取数据，
  IDataPipeTo只能将数据推送到数据源，为什么要区分这两种不同的管道？

  答：因为数据的来源和去向有可能不同，举个例子，
  有时候需要把从Excel中提取出来的数据导入数据库，
  另外有些数据源并不支持完整的增删改查功能，例如，
  如果一个数据是通过爬虫获取的，那么它不支持添加修改和删除
   
  问：实现IDataPipeFrom和IDataPipeTo需要遵循哪些规范？

  答：请遵循以下规范：
  #这些接口被设计为自我描述，也就是说，当它们被实例化的时候，
  就已经知道数据应该从哪里来，或者应该被添加到什么地方，不需要任何额外的参数或说明，
  举例来说，如果你想要查询数据库中某个表的数据，那么你就应该通过DB对象返回一个Table对象，
  并将Table对象实现IDataPipeFrom接口，以后所有通过这个对象进行的查询，都是在查询数据库中的这张表，
  而不是传入一个参数告诉数据位于数据库的什么位置，然后再进行查询

  这样设计带来的好处有三点：
  1.能够让数据模型变得直观
  2.能够把对任何数据源的查询都变成LinqToObject的形式，
  你可以把这些数据源全部想象为内存中的一个集合，
  它是高度抽象的，只提供增删改查四种功能，
  无论它们来自哪里，或者内部有多么复杂，在外部看来都没什么区别
  3.提供更强大的可扩展性，因为这种设计着重于返回管道，而不是直接返回数据
   
  #应该把数据源设计为不可变的，因为这种模型非常依赖正确的数据源，如果在这方面出现问题，会很难排查
   
  #在添加或查询数据的时候，接口的实现者有义务检查数据的架构，
  如果架构不一致，应该立即引发异常，这样可以使一些问题被尽快发现，
  如果数据来自数据库等结构化数据源，则这个过程可以省略

  问：在本框架的早期版本，管道不需要显式向数据源推送数据，
  而是通过IData上的一个绑定对象来自动完成这个过程，
  这种操作非常方便，那么为什么最后被废弃了？
  答：以下原因分先后：
  
  1.这种设计不方便前后端分离，因为前端很可能根本就不是用net开发的，
  那么，如何获取IData对象并正确地执行绑定？
  2.这种设计不方便精确地控制向数据源推送数据的时机，
  而在前端开发中需要这种功能*/